home *** CD-ROM | disk | FTP | other *** search
/ SGI Freeware 1999 August / SGI Freeware 1999 August.iso / dist / fw_cvs.idb / usr / freeware / info / cvs.info-3.z / cvs.info-3
Encoding:
GNU Info File  |  1999-04-16  |  49.7 KB  |  1,321 lines
  1. This is Info file cvs.info, produced by Makeinfo version 1.67 from the
  2. input file ./cvs.texinfo.
  3.  
  4. START-INFO-DIR-ENTRY
  5. * CVS: (cvs).          Concurrent Versions System
  6. END-INFO-DIR-ENTRY
  7.  
  8.    Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994
  9. Free Software Foundation, Inc.
  10.  
  11.    Permission is granted to make and distribute verbatim copies of this
  12. manual provided the copyright notice and this permission notice are
  13. preserved on all copies.
  14.  
  15.    Permission is granted to copy and distribute modified versions of
  16. this manual under the conditions for verbatim copying, provided also
  17. that the entire resulting derived work is distributed under the terms
  18. of a permission notice identical to this one.
  19.  
  20.    Permission is granted to copy and distribute translations of this
  21. manual into another language, under the above conditions for modified
  22. versions, except that this permission notice may be stated in a
  23. translation approved by the Free Software Foundation.
  24.  
  25. 
  26. File: cvs.info,  Node: Creating a branch,  Next: Accessing branches,  Prev: Branches motivation,  Up: Branching and merging
  27.  
  28. Creating a branch
  29. =================
  30.  
  31.    You can create a branch with `tag -b'; for example, assuming you're
  32. in a working copy:
  33.  
  34.      $ cvs tag -b rel-1-0-patches
  35.  
  36.    This splits off a branch based on the current revisions in the
  37. working copy, assigning that branch the name `rel-1-0-patches'.
  38.  
  39.    It is important to understand that branches get created in the
  40. repository, not in the working copy.  Creating a branch based on
  41. current revisions, as the above example does, will *not* automatically
  42. switch the working copy to be on the new branch.  For information on how
  43. to do that, see *Note Accessing branches::.
  44.  
  45.    You can also create a branch without reference to any working copy,
  46. by using `rtag':
  47.  
  48.      $ cvs rtag -b -r rel-1-0 rel-1-0-patches tc
  49.  
  50.    `-r rel-1-0' says that this branch should be rooted at the revision
  51. that corresponds to the tag `rel-1-0'.  It need not be the most recent
  52. revision - it's often useful to split a branch off an old revision (for
  53. example, when fixing a bug in a past release otherwise known to be
  54. stable).
  55.  
  56.    As with `tag', the `-b' flag tells `rtag' to create a branch (rather
  57. than just a symbolic revision name).  Note that the numeric revision
  58. number that matches `rel-1-0' will probably be different from file to
  59. file.
  60.  
  61.    So, the full effect of the command is to create a new branch - named
  62. `rel-1-0-patches' - in module `tc', rooted in the revision tree at the
  63. point tagged by `rel-1-0'.
  64.  
  65. 
  66. File: cvs.info,  Node: Accessing branches,  Next: Branches and revisions,  Prev: Creating a branch,  Up: Branching and merging
  67.  
  68. Accessing branches
  69. ==================
  70.  
  71.    You can retrieve a branch in one of two ways: by checking it out
  72. fresh from the repository, or by switching an existing working copy
  73. over to the branch.
  74.  
  75.    To check out a branch from the repository, invoke `checkout' with
  76. the `-r' flag, followed by the tag name of the branch (*note Creating a
  77. branch::.):
  78.  
  79.      $ cvs checkout -r rel-1-0-patches tc
  80.  
  81.    Or, if you already have a working copy, you can switch it to a given
  82. branch with `update -r':
  83.  
  84.      $ cvs update -r rel-1-0-patches tc
  85.  
  86.    or equivalently:
  87.  
  88.      $ cd tc
  89.      $ cvs update -r rel-1-0-patches
  90.  
  91.    It does not matter if the working copy was originally on the main
  92. trunk or on some other branch - the above command will switch it to the
  93. named branch.  And similarly to a regular `update' command, `update -r'
  94. merges any changes you have made, notifying you of conflicts where they
  95. occur.
  96.  
  97.    Once you have a working copy tied to a particular branch, it remains
  98. there until you tell it otherwise.  This means that changes checked in
  99. from the working copy will add new revisions on that branch, while
  100. leaving the main trunk and other branches unaffected.
  101.  
  102.    To find out what branch a working copy is on, you can use the
  103. `status' command.  In its output, look for the field named `Sticky tag'
  104. (*note Sticky tags::.) - that's CVS's way of telling you the branch, if
  105. any, of the current working files:
  106.  
  107.      $ cvs status -v driver.c backend.c
  108.      ===================================================================
  109.      File: driver.c          Status: Up-to-date
  110.      
  111.          Version:            1.7     Sat Dec  5 18:25:54 1992
  112.          RCS Version:        1.7     /u/cvsroot/yoyodyne/tc/driver.c,v
  113.          Sticky Tag:         rel-1-0-patches (branch: 1.7.2)
  114.          Sticky Date:        (none)
  115.          Sticky Options:     (none)
  116.      
  117.          Existing Tags:
  118.              rel-1-0-patches             (branch: 1.7.2)
  119.              rel-1-0                     (revision: 1.7)
  120.      
  121.      ===================================================================
  122.      File: backend.c         Status: Up-to-date
  123.      
  124.          Version:            1.4     Tue Dec  1 14:39:01 1992
  125.          RCS Version:        1.4     /u/cvsroot/yoyodyne/tc/backend.c,v
  126.          Sticky Tag:         rel-1-0-patches (branch: 1.4.2)
  127.          Sticky Date:        (none)
  128.          Sticky Options:     (none)
  129.      
  130.          Existing Tags:
  131.              rel-1-0-patches             (branch: 1.4.2)
  132.              rel-1-0                     (revision: 1.4)
  133.              rel-0-4                     (revision: 1.4)
  134.  
  135.    Don't be confused by the fact that the branch numbers for each file
  136. are different (`1.7.2' and `1.4.2' respectively).  The branch tag is the
  137. same, `rel-1-0-patches', and the files are indeed on the same branch.
  138. The numbers simply reflect the point in each file's revision history at
  139. which the branch was made.  In the above example, one can deduce that
  140. `driver.c' had been through more changes than `backend.c' before this
  141. branch was created.
  142.  
  143.    See *Note Branches and revisions:: for details about how branch
  144. numbers are constructed.
  145.  
  146. 
  147. File: cvs.info,  Node: Branches and revisions,  Next: Magic branch numbers,  Prev: Accessing branches,  Up: Branching and merging
  148.  
  149. Branches and revisions
  150. ======================
  151.  
  152.    Ordinarily, a file's revision history is a linear series of
  153. increments (*note Revision numbers::.):
  154.  
  155.             +-----+    +-----+    +-----+    +-----+    +-----+
  156.             ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
  157.             +-----+    +-----+    +-----+    +-----+    +-----+
  158.  
  159.    However, CVS is not limited to linear development.  The "revision
  160. tree" can be split into "branches", where each branch is a
  161. self-maintained line of development.  Changes made on one branch can
  162. easily be moved back to the main trunk.
  163.  
  164.    Each branch has a "branch number", consisting of an odd number of
  165. period-separated decimal integers.  The branch number is created by
  166. appending an integer to the revision number where the corresponding
  167. branch forked off.  Having branch numbers allows more than one branch
  168. to be forked off from a certain revision.
  169.  
  170.    All revisions on a branch have revision numbers formed by appending
  171. an ordinal number to the branch number.  The following figure
  172. illustrates branching with an example.
  173.  
  174.                                            +-------------+
  175.                 Branch 1.2.2.3.2 ->        ! 1.2.2.3.2.1 !
  176.                                          / +-------------+
  177.                                         /
  178.                                        /
  179.                       +---------+    +---------+    +---------+
  180.      Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
  181.                     / +---------+    +---------+    +---------+
  182.                    /
  183.                   /
  184.      +-----+    +-----+    +-----+    +-----+    +-----+
  185.      ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !  <- The main trunk
  186.      +-----+    +-----+    +-----+    +-----+    +-----+
  187.                      !
  188.                      !
  189.                      !   +---------+    +---------+    +---------+
  190.      Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
  191.                          +---------+    +---------+    +---------+
  192.  
  193.    The exact details of how the branch number is constructed is not
  194. something you normally need to be concerned about, but here is how it
  195. works: When CVS creates a branch number it picks the first unused even
  196. integer, starting with 2.  So when you want to create a branch from
  197. revision 6.4 it will be numbered 6.4.2.  All branch numbers ending in a
  198. zero (such as 6.4.0) are used internally by CVS (*note Magic branch
  199. numbers::.).  The branch 1.1.1 has a special meaning.  *Note Tracking
  200. sources::.
  201.  
  202. 
  203. File: cvs.info,  Node: Magic branch numbers,  Next: Merging a branch,  Prev: Branches and revisions,  Up: Branching and merging
  204.  
  205. Magic branch numbers
  206. ====================
  207.  
  208.    This section describes a CVS feature called "magic branches".  For
  209. most purposes, you need not worry about magic branches; CVS handles
  210. them for you.  However, they are visible to you in certain
  211. circumstances, so it may be useful to have some idea of how it works.
  212.  
  213.    Externally, branch numbers consist of an odd number of dot-separated
  214. decimal integers.  *Note Revision numbers::.  That is not the whole
  215. truth, however.  For efficiency reasons CVS sometimes inserts an extra 0
  216. in the second rightmost position (1.2.4 becomes 1.2.0.4, 8.9.10.11.12
  217. becomes 8.9.10.11.0.12 and so on).
  218.  
  219.    CVS does a pretty good job at hiding these so called magic branches,
  220. but in a few places the hiding is incomplete:
  221.  
  222.    * The magic branch number appears in the output from `cvs log'.
  223.  
  224.    * You cannot specify a symbolic branch name to `cvs admin'.
  225.  
  226.    You can use the `admin' command to reassign a symbolic name to a
  227. branch the way RCS expects it to be.  If `R4patches' is assigned to the
  228. branch 1.4.2 (magic branch number 1.4.0.2) in file `numbers.c' you can
  229. do this:
  230.  
  231.      $ cvs admin -NR4patches:1.4.2 numbers.c
  232.  
  233.    It only works if at least one revision is already committed on the
  234. branch.  Be very careful so that you do not assign the tag to the wrong
  235. number.  (There is no way to see how the tag was assigned yesterday).
  236.  
  237. 
  238. File: cvs.info,  Node: Merging a branch,  Next: Merging more than once,  Prev: Magic branch numbers,  Up: Branching and merging
  239.  
  240. Merging an entire branch
  241. ========================
  242.  
  243.    You can merge changes made on a branch into your working copy by
  244. giving the `-j BRANCH' flag to the `update' command.  With one `-j
  245. BRANCH' option it merges the changes made between the point where the
  246. branch forked and newest revision on that branch (into your working
  247. copy).
  248.  
  249.    The `-j' stands for "join".
  250.  
  251.    Consider this revision tree:
  252.  
  253.      +-----+    +-----+    +-----+    +-----+
  254.      ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !      <- The main trunk
  255.      +-----+    +-----+    +-----+    +-----+
  256.                      !
  257.                      !
  258.                      !   +---------+    +---------+
  259.      Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
  260.                          +---------+    +---------+
  261.  
  262. The branch 1.2.2 has been given the tag (symbolic name) `R1fix'.  The
  263. following example assumes that the module `mod' contains only one file,
  264. `m.c'.
  265.  
  266.      $ cvs checkout mod               # Retrieve the latest revision, 1.4
  267.      
  268.      $ cvs update -j R1fix m.c        # Merge all changes made on the branch,
  269.                                       # i.e. the changes between revision 1.2
  270.                                       # and 1.2.2.2, into your working copy
  271.                                       # of the file.
  272.      
  273.      $ cvs commit -m "Included R1fix" # Create revision 1.5.
  274.  
  275.    A conflict can result from a merge operation.  If that happens, you
  276. should resolve it before committing the new revision.  *Note Conflicts
  277. example::.
  278.  
  279.    The `checkout' command also supports the `-j BRANCH' flag.  The same
  280. effect as above could be achieved with this:
  281.  
  282.      $ cvs checkout -j R1fix mod
  283.      $ cvs commit -m "Included R1fix"
  284.  
  285. 
  286. File: cvs.info,  Node: Merging more than once,  Next: Merging two revisions,  Prev: Merging a branch,  Up: Branching and merging
  287.  
  288. Merging from a branch several times
  289. ===================================
  290.  
  291.    Continuing our example, the revision tree now looks like this:
  292.  
  293.      +-----+    +-----+    +-----+    +-----+    +-----+
  294.      ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
  295.      +-----+    +-----+    +-----+    +-----+    +-----+
  296.                      !                           *
  297.                      !                          *
  298.                      !   +---------+    +---------+
  299.      Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
  300.                          +---------+    +---------+
  301.  
  302.    where the starred line represents the merge from the `R1fix' branch
  303. to the main trunk, as just discussed.
  304.  
  305.    Now suppose that development continues on the `R1fix' branch:
  306.  
  307.      +-----+    +-----+    +-----+    +-----+    +-----+
  308.      ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
  309.      +-----+    +-----+    +-----+    +-----+    +-----+
  310.                      !                           *
  311.                      !                          *
  312.                      !   +---------+    +---------+    +---------+
  313.      Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
  314.                          +---------+    +---------+    +---------+
  315.  
  316.    and then you want to merge those new changes onto the main trunk.
  317. If you just use the `cvs update -j R1fix m.c' command again, CVS will
  318. attempt to merge again the changes which you have already merged, which
  319. can have undesirable side effects.
  320.  
  321.    So instead you need to specify that you only want to merge the
  322. changes on the branch which have not yet been merged into the trunk.
  323. To do that you specify two `-j' options, and CVS merges the changes from
  324. the first revision to the second revision.  For example, in this case
  325. the simplest way would be
  326.  
  327.      cvs update -j 1.2.2.2 -j R1fix m.c    # Merge changes from 1.2.2.2 to the
  328.                                            # head of the R1fix branch
  329.  
  330.    The problem with this is that you need to specify the 1.2.2.2
  331. revision manually.  A slightly better approach might be to use the date
  332. the last merge was done:
  333.  
  334.      cvs update -j R1fix:yesterday -j R1fix m.c
  335.  
  336.    Better yet, tag the R1fix branch after every merge into the trunk,
  337. and then use that tag for subsequent merges:
  338.  
  339.      cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
  340.  
  341. 
  342. File: cvs.info,  Node: Merging two revisions,  Next: Merging adds and removals,  Prev: Merging more than once,  Up: Branching and merging
  343.  
  344. Merging differences between any two revisions
  345. =============================================
  346.  
  347.    With two `-j REVISION' flags, the `update' (and `checkout') command
  348. can merge the differences between any two revisions into your working
  349. file.
  350.  
  351.      $ cvs update -j 1.5 -j 1.3 backend.c
  352.  
  353. will *remove* all changes made between revision 1.3 and 1.5.  Note the
  354. order of the revisions!
  355.  
  356.    If you try to use this option when operating on multiple files,
  357. remember that the numeric revisions will probably be very different
  358. between the various files that make up a module.  You almost always use
  359. symbolic tags rather than revision numbers when operating on multiple
  360. files.
  361.  
  362. 
  363. File: cvs.info,  Node: Merging adds and removals,  Prev: Merging two revisions,  Up: Branching and merging
  364.  
  365. Merging can add or remove files
  366. ===============================
  367.  
  368.    If the changes which you are merging involve removing or adding some
  369. files, `update -j' will reflect such additions or removals.
  370.  
  371.    For example:
  372.      cvs update -A
  373.      touch a b c
  374.      cvs add a b c ; cvs ci -m "added" a b c
  375.      cvs tag -b branchtag
  376.      cvs update -r branchtag
  377.      touch d ; cvs add d
  378.      rm a ; cvs rm a
  379.      cvs ci -m "added d, removed a"
  380.      cvs update -A
  381.      cvs update -jbranchtag
  382.  
  383.    After these commands are executed and a `cvs commit' is done, file
  384. `a' will be removed and file `d' added in the main branch.
  385.  
  386. 
  387. File: cvs.info,  Node: Recursive behavior,  Next: Adding and removing,  Prev: Branching and merging,  Up: Top
  388.  
  389. Recursive behavior
  390. ******************
  391.  
  392.    Almost all of the subcommands of CVS work recursively when you
  393. specify a directory as an argument.  For instance, consider this
  394. directory structure:
  395.  
  396.            `$HOME'
  397.              |
  398.              +--tc
  399.              |   |
  400.                  +--CVS
  401.                  |      (internal CVS files)
  402.                  +--Makefile
  403.                  +--backend.c
  404.                  +--driver.c
  405.                  +--frontend.c
  406.                  +--parser.c
  407.                  +--man
  408.                  |    |
  409.                  |    +--CVS
  410.                  |    |  (internal CVS files)
  411.                  |    +--tc.1
  412.                  |
  413.                  +--testing
  414.                       |
  415.                       +--CVS
  416.                       |  (internal CVS files)
  417.                       +--testpgm.t
  418.                       +--test2.t
  419.  
  420. If `tc' is the current working directory, the following is true:
  421.  
  422.    * `cvs update testing' is equivalent to
  423.  
  424.           cvs update testing/testpgm.t testing/test2.t
  425.  
  426.    * `cvs update testing man' updates all files in the subdirectories
  427.  
  428.    * `cvs update .' or just `cvs update' updates all files in the `tc'
  429.      module
  430.  
  431.    If no arguments are given to `update' it will update all files in
  432. the current working directory and all its subdirectories.  In other
  433. words, `.' is a default argument to `update'.  This is also true for
  434. most of the CVS subcommands, not only the `update' command.
  435.  
  436.    The recursive behavior of the CVS subcommands can be turned off with
  437. the `-l' option.  Conversely, the `-R' option can be used to force
  438. recursion if `-l' is specified in `~/.cvsrc' (*note ~/.cvsrc::.).
  439.  
  440.      $ cvs update -l         # Don't update files in subdirectories
  441.  
  442. 
  443. File: cvs.info,  Node: Adding and removing,  Next: History browsing,  Prev: Recursive behavior,  Up: Top
  444.  
  445. Adding, removing, and renaming files and directories
  446. ****************************************************
  447.  
  448.    In the course of a project, one will often add new files.  Likewise
  449. with removing or renaming, or with directories.  The general concept to
  450. keep in mind in all these cases is that instead of making an
  451. irreversible change you want CVS to record the fact that a change has
  452. taken place, just as with modifying an existing file.  The exact
  453. mechanisms to do this in CVS vary depending on the situation.
  454.  
  455. * Menu:
  456.  
  457. * Adding files::                Adding files
  458. * Removing files::              Removing files
  459. * Removing directories::        Removing directories
  460. * Moving files::                Moving and renaming files
  461. * Moving directories::          Moving and renaming directories
  462.  
  463. 
  464. File: cvs.info,  Node: Adding files,  Next: Removing files,  Up: Adding and removing
  465.  
  466. Adding files to a directory
  467. ===========================
  468.  
  469.    To add a new file to a directory, follow these steps.
  470.  
  471.    * You must have a working copy of the directory.  *Note Getting the
  472.      source::.
  473.  
  474.    * Create the new file inside your working copy of the directory.
  475.  
  476.    * Use `cvs add FILENAME' to tell CVS that you want to version
  477.      control the file.  If the file contains binary data, specify `-kb'
  478.      (*note Binary files::.).
  479.  
  480.    * Use `cvs commit FILENAME' to actually check in the file into the
  481.      repository.  Other developers cannot see the file until you
  482.      perform this step.
  483.  
  484.    You can also use the `add' command to add a new directory.
  485.  
  486.    Unlike most other commands, the `add' command is not recursive.  You
  487. cannot even type `cvs add foo/bar'!  Instead, you have to
  488.  
  489.      $ cd foo
  490.      $ cvs add bar
  491.  
  492.  - Command: cvs add [`-k' KFLAG] [`-m' MESSAGE] FILES ...
  493.      Schedule FILES to be added to the repository.  The files or
  494.      directories specified with `add' must already exist in the current
  495.      directory.  To add a whole new directory hierarchy to the source
  496.      repository (for example, files received from a third-party
  497.      vendor), use the `import' command instead.  *Note import::.
  498.  
  499.      The added files are not placed in the source repository until you
  500.      use `commit' to make the change permanent.  Doing an `add' on a
  501.      file that was removed with the `remove' command will undo the
  502.      effect of the `remove', unless a `commit' command intervened.
  503.      *Note Removing files::, for an example.
  504.  
  505.      The `-k' option specifies the default way that this file will be
  506.      checked out; for more information see *Note Substitution modes::.
  507.  
  508.      The `-m' option specifies a description for the file.  This
  509.      description appears in the history log (if it is enabled, *note
  510.      history file::.).  It will also be saved in the version history
  511.      inside the repository when the file is committed.  The `log'
  512.      command displays this description.  The description can be changed
  513.      using `admin -t'.  *Note admin::.  If you omit the `-m
  514.      DESCRIPTION' flag, an empty string will be used.  You will not be
  515.      prompted for a description.
  516.  
  517.    For example, the following commands add the file `backend.c' to the
  518. repository:
  519.  
  520.      $ cvs add backend.c
  521.      $ cvs commit -m "Early version. Not yet compilable." backend.c
  522.  
  523.    When you add a file it is added only on the branch which you are
  524. working on (*note Branching and merging::.).  You can later merge the
  525. additions to another branch if you want (*note Merging adds and
  526. removals::.).
  527.  
  528. 
  529. File: cvs.info,  Node: Removing files,  Next: Removing directories,  Prev: Adding files,  Up: Adding and removing
  530.  
  531. Removing files
  532. ==============
  533.  
  534.    Modules change.  New files are added, and old files disappear.
  535. Still, you want to be able to retrieve an exact copy of old releases.
  536.  
  537.    Here is what you can do to remove a file, but remain able to
  538. retrieve old revisions:
  539.  
  540.    * Make sure that you have not made any uncommitted modifications to
  541.      the file.  *Note Viewing differences::, for one way to do that.
  542.      You can also use the `status' or `update' command.  If you remove
  543.      the file without committing your changes, you will of course not
  544.      be able to retrieve the file as it was immediately before you
  545.      deleted it.
  546.  
  547.    * Remove the file from your working copy of the directory.  You can
  548.      for instance use `rm'.
  549.  
  550.    * Use `cvs remove FILENAME' to tell CVS that you really want to
  551.      delete the file.
  552.  
  553.    * Use `cvs commit FILENAME' to actually perform the removal of the
  554.      file from the repository.
  555.  
  556.    When you commit the removal of the file, CVS records the fact that
  557. the file no longer exists.  It is possible for a file to exist on only
  558. some branches and not on others, or to re-add another file with the same
  559. name later.  CVS will correctly create or not create the file, based on
  560. the `-r' and `-D' options specified to `checkout' or `update'.
  561.  
  562.  - Command: cvs remove [OPTIONS] FILES ...
  563.      Schedule file(s) to be removed from the repository (files which
  564.      have not already been removed from the working directory are not
  565.      processed).  This command does not actually remove the file from
  566.      the repository until you commit the removal.  For a full list of
  567.      options, see *Note Invoking CVS::.
  568.  
  569.    Here is an example of removing several files:
  570.  
  571.      $ cd test
  572.      $ rm *.c
  573.      $ cvs remove
  574.      cvs remove: Removing .
  575.      cvs remove: scheduling a.c for removal
  576.      cvs remove: scheduling b.c for removal
  577.      cvs remove: use 'cvs commit' to remove these files permanently
  578.      $ cvs ci -m "Removed unneeded files"
  579.      cvs commit: Examining .
  580.      cvs commit: Committing .
  581.  
  582.    As a convenience you can remove the file and `cvs remove' it in one
  583. step, by specifying the `-f' option.  For example, the above example
  584. could also be done like this:
  585.  
  586.      $ cd test
  587.      $ cvs remove -f *.c
  588.      cvs remove: scheduling a.c for removal
  589.      cvs remove: scheduling b.c for removal
  590.      cvs remove: use 'cvs commit' to remove these files permanently
  591.      $ cvs ci -m "Removed unneeded files"
  592.      cvs commit: Examining .
  593.      cvs commit: Committing .
  594.  
  595.    If you execute `remove' for a file, and then change your mind before
  596. you commit, you can undo the `remove' with an `add' command.
  597.  
  598.      $ ls
  599.      CVS   ja.h  oj.c
  600.      $ rm oj.c
  601.      $ cvs remove oj.c
  602.      cvs remove: scheduling oj.c for removal
  603.      cvs remove: use 'cvs commit' to remove this file permanently
  604.      $ cvs add oj.c
  605.      U oj.c
  606.      cvs add: oj.c, version 1.1.1.1, resurrected
  607.  
  608.    If you realize your mistake before you run the `remove' command you
  609. can use `update' to resurrect the file:
  610.  
  611.      $ rm oj.c
  612.      $ cvs update oj.c
  613.      cvs update: warning: oj.c was lost
  614.      U oj.c
  615.  
  616.    When you remove a file it is removed only on the branch which you
  617. are working on (*note Branching and merging::.).  You can later merge
  618. the removals to another branch if you want (*note Merging adds and
  619. removals::.).
  620.  
  621. 
  622. File: cvs.info,  Node: Removing directories,  Next: Moving files,  Prev: Removing files,  Up: Adding and removing
  623.  
  624. Removing directories
  625. ====================
  626.  
  627.    In concept removing directories is somewhat similar to removing
  628. files--you want the directory to not exist in your current working
  629. directories, but you also want to be able to retrieve old releases in
  630. which the directory existed.
  631.  
  632.    The way that you remove a directory is to remove all the files in
  633. it.  You don't remove the directory itself; there is no way to do that.
  634. Instead you specify the `-P' option to `cvs update', `cvs checkout', or
  635. `cvs export', which will cause CVS to remove empty directories from
  636. working directories.  Probably the best way to do this is to always
  637. specify `-P'; if you want an empty directory then put a dummy file (for
  638. example `.keepme') in it to prevent `-P' from removing it.
  639.  
  640.    Note that `-P' is implied by the `-r' or `-D' options of `checkout'
  641. and `export'.  This way CVS will be able to correctly create the
  642. directory or not depending on whether the particular version you are
  643. checking out contains any files in that directory.
  644.  
  645. 
  646. File: cvs.info,  Node: Moving files,  Next: Moving directories,  Prev: Removing directories,  Up: Adding and removing
  647.  
  648. Moving and renaming files
  649. =========================
  650.  
  651.    Moving files to a different directory or renaming them is not
  652. difficult, but some of the ways in which this works may be non-obvious.
  653. (Moving or renaming a directory is even harder.  *Note Moving
  654. directories::.).
  655.  
  656.    The examples below assume that the file OLD is renamed to NEW.
  657.  
  658. * Menu:
  659.  
  660. * Outside::                     The normal way to Rename
  661. * Inside::                      A tricky, alternative way
  662. * Rename by copying::           Another tricky, alternative way
  663.  
  664. 
  665. File: cvs.info,  Node: Outside,  Next: Inside,  Up: Moving files
  666.  
  667. The Normal way to Rename
  668. ------------------------
  669.  
  670.    The normal way to move a file is to copy OLD to NEW, and then issue
  671. the normal CVS commands to remove OLD from the repository, and add NEW
  672. to it.
  673.  
  674.      $ mv OLD NEW
  675.      $ cvs remove OLD
  676.      $ cvs add NEW
  677.      $ cvs commit -m "Renamed OLD to NEW" OLD NEW
  678.  
  679.    This is the simplest way to move a file, it is not error-prone, and
  680. it preserves the history of what was done.  Note that to access the
  681. history of the file you must specify the old or the new name, depending
  682. on what portion of the history you are accessing.  For example, `cvs
  683. log OLD' will give the log up until the time of the rename.
  684.  
  685.    When NEW is committed its revision numbers will start again, usually
  686. at 1.1, so if that bothers you, use the `-r rev' option to commit.  For
  687. more information see *Note Assigning revisions::.
  688.  
  689. 
  690. File: cvs.info,  Node: Inside,  Next: Rename by copying,  Prev: Outside,  Up: Moving files
  691.  
  692. Moving the history file
  693. -----------------------
  694.  
  695.    This method is more dangerous, since it involves moving files inside
  696. the repository.  Read this entire section before trying it out!
  697.  
  698.      $ cd $CVSROOT/MODULE
  699.      $ mv OLD,v NEW,v
  700.  
  701. Advantages:
  702.  
  703.    * The log of changes is maintained intact.
  704.  
  705.    * The revision numbers are not affected.
  706.  
  707. Disadvantages:
  708.  
  709.    * Old releases of the module cannot easily be fetched from the
  710.      repository.  (The file will show up as NEW even in revisions from
  711.      the time before it was renamed).
  712.  
  713.    * There is no log information of when the file was renamed.
  714.  
  715.    * Nasty things might happen if someone accesses the history file
  716.      while you are moving it.  Make sure no one else runs any of the CVS
  717.      commands while you move it.
  718.  
  719. 
  720. File: cvs.info,  Node: Rename by copying,  Prev: Inside,  Up: Moving files
  721.  
  722. Copying the history file
  723. ------------------------
  724.  
  725.    This way also involves direct modifications to the repository.  It
  726. is safe, but not without drawbacks.
  727.  
  728.      # Copy the RCS file inside the repository
  729.      $ cd $CVSROOT/MODULE
  730.      $ cp OLD,v NEW,v
  731.      # Remove the old file
  732.      $ cd ~/MODULE
  733.      $ rm OLD
  734.      $ cvs remove OLD
  735.      $ cvs commit OLD
  736.      # Remove all tags from NEW
  737.      $ cvs update NEW
  738.      $ cvs log NEW             # Remember the non-branch tag names
  739.      $ cvs tag -d TAG1 NEW
  740.      $ cvs tag -d TAG2 NEW
  741.      ...
  742.  
  743.    By removing the tags you will be able to check out old revisions of
  744. the module.
  745.  
  746. Advantages:
  747.  
  748.    * Checking out old revisions works correctly, as long as you use
  749.      `-rTAG' and not `-DDATE' to retrieve the revisions.
  750.  
  751.    * The log of changes is maintained intact.
  752.  
  753.    * The revision numbers are not affected.
  754.  
  755. Disadvantages:
  756.  
  757.    * You cannot easily see the history of the file across the rename.
  758.  
  759. 
  760. File: cvs.info,  Node: Moving directories,  Prev: Moving files,  Up: Adding and removing
  761.  
  762. Moving and renaming directories
  763. ===============================
  764.  
  765.    The normal way to rename or move a directory is to rename or move
  766. each file within it as described in *Note Outside::.  Then check out
  767. with the `-P' option, as described in *Note Removing directories::.
  768.  
  769.    If you really want to hack the repository to rename or delete a
  770. directory in the repository, you can do it like this:
  771.  
  772.   1. Inform everyone who has a copy of the module that the directory
  773.      will be renamed.  They should commit all their changes, and remove
  774.      their working copies of the module, before you take the steps
  775.      below.
  776.  
  777.   2. Rename the directory inside the repository.
  778.  
  779.           $ cd $CVSROOT/MODULE
  780.           $ mv OLD-DIR NEW-DIR
  781.  
  782.   3. Fix the CVS administrative files, if necessary (for instance if
  783.      you renamed an entire module).
  784.  
  785.   4. Tell everyone that they can check out the module and continue
  786.      working.
  787.  
  788.  
  789.    If someone had a working copy of the module the CVS commands will
  790. cease to work for him, until he removes the directory that disappeared
  791. inside the repository.
  792.  
  793.    It is almost always better to move the files in the directory
  794. instead of moving the directory.  If you move the directory you are
  795. unlikely to be able to retrieve old releases correctly, since they
  796. probably depend on the name of the directories.
  797.  
  798. 
  799. File: cvs.info,  Node: History browsing,  Next: Binary files,  Prev: Adding and removing,  Up: Top
  800.  
  801. History browsing
  802. ****************
  803.  
  804.    Once you have used CVS to store a version control history--what
  805. files have changed when, how, and by whom, there are a variety of
  806. mechanisms for looking through the history.
  807.  
  808. * Menu:
  809.  
  810. * log messages::                Log messages
  811. * history database::            The history database
  812. * user-defined logging::        User-defined logging
  813. * annotate::                    What revision modified each line of a file?
  814.  
  815. 
  816. File: cvs.info,  Node: log messages,  Next: history database,  Up: History browsing
  817.  
  818. Log messages
  819. ============
  820.  
  821.    Whenever you commit a file you specify a log message.
  822.  
  823.    To look through the log messages which have been specified for every
  824. revision which has been committed, use the `cvs log' command (*note
  825. log::.).
  826.  
  827. 
  828. File: cvs.info,  Node: history database,  Next: user-defined logging,  Prev: log messages,  Up: History browsing
  829.  
  830. The history database
  831. ====================
  832.  
  833.    You can use the history file (*note history file::.) to log various
  834. CVS actions.  To retrieve the information from the history file, use
  835. the `cvs history' command (*note history::.).
  836.  
  837. 
  838. File: cvs.info,  Node: user-defined logging,  Next: annotate,  Prev: history database,  Up: History browsing
  839.  
  840. User-defined logging
  841. ====================
  842.  
  843.    You can customize CVS to log various kinds of actions, in whatever
  844. manner you choose.  These mechanisms operate by executing a script at
  845. various times.  The script might append a message to a file listing the
  846. information and the programmer who created it, or send mail to a group
  847. of developers, or, perhaps, post a message to a particular newsgroup.
  848. To log commits, use the `loginfo' file (*note loginfo::.).  To log
  849. commits, checkouts, exports, and tags, respectively, you can also use
  850. the `-i', `-o', `-e', and `-t' options in the modules file.  For a more
  851. flexible way of giving notifications to various users, which requires
  852. less in the way of keeping centralized scripts up to date, use the `cvs
  853. watch add' command (*note Getting Notified::.); this command is useful
  854. even if you are not using `cvs watch on'.
  855.  
  856.    The `taginfo' file defines programs to execute when someone executes
  857. a `tag' or `rtag' command.  The `taginfo' file has the standard form
  858. for administrative files (*note Administrative files::.), where each
  859. line is a regular expression followed by a command to execute.  The
  860. arguments passed to the command are, in order, the TAGNAME, OPERATION
  861. (`add' for `tag', `mov' for `tag -F', and `del' for `tag -d'),
  862. REPOSITORY, and any remaining are pairs of FILENAME REVISION.  A
  863. non-zero exit of the filter program will cause the tag to be aborted.
  864.  
  865.    Here is an example of using taginfo to log tag and rtag commands.
  866. In the taginfo file put:
  867.  
  868.      ALL /usr/local/cvsroot/CVSROOT/loggit
  869.  
  870.    Where `/usr/local/cvsroot/CVSROOT/loggit' contains the following
  871. script:
  872.  
  873.      #!/bin/sh
  874.      echo "$@" >>/home/kingdon/cvsroot/CVSROOT/taglog
  875.  
  876. 
  877. File: cvs.info,  Node: annotate,  Prev: user-defined logging,  Up: History browsing
  878.  
  879. Annotate command
  880. ================
  881.  
  882.  - Command: cvs annotate [`-flR'] [`-r rev'|`-D date'] FILES ...
  883.      For each file in FILES, print the head revision of the trunk,
  884.      together with information on the last modification for each line.
  885.      For example:
  886.  
  887.           $ cvs annotate ssfile
  888.           Annotations for ssfile
  889.           ***************
  890.           1.1          (mary     27-Mar-96): ssfile line 1
  891.           1.2          (joe      28-Mar-96): ssfile line 2
  892.  
  893.      The file `ssfile' currently contains two lines.  The `ssfile line
  894.      1' line was checked in by `mary' on March 27.  Then, on March 28,
  895.      `joe' added a line `ssfile line 2', without modifying the `ssfile
  896.      line 1' line.  This report doesn't tell you anything about lines
  897.      which have been deleted or replaced; you need to use `cvs diff'
  898.      for that (*note diff::.).
  899.  
  900.  
  901.    The options to `cvs annotate' are listed in *Note Invoking CVS::,
  902. and can be used to select the files and revisions to annotate.  The
  903. options are described in more detail in *Note Common options::.
  904.  
  905. 
  906. File: cvs.info,  Node: Binary files,  Next: Multiple developers,  Prev: History browsing,  Up: Top
  907.  
  908. Handling binary files
  909. *********************
  910.  
  911.    The most common use for CVS is to store text files.  With text
  912. files, CVS can merge revisions, display the differences between
  913. revisions in a human-visible fashion, and other such operations.
  914. However, if you are willing to give up a few of these abilities, CVS
  915. can store binary files.  For example, one might store a web site in CVS
  916. including both text files and binary images.
  917.  
  918. * Menu:
  919.  
  920. * Binary why::     More details on issues with binary files
  921. * Binary howto::   How to store them
  922.  
  923. 
  924. File: cvs.info,  Node: Binary why,  Next: Binary howto,  Up: Binary files
  925.  
  926. The issues with binary files
  927. ============================
  928.  
  929.    While the need to manage binary files may seem obvious if the files
  930. that you customarily work with are binary, putting them into version
  931. control does present some additional issues.
  932.  
  933.    One basic function of version control is to show the differences
  934. between two revisions.  For example, if someone else checked in a new
  935. version of a file, you may wish to look at what they changed and
  936. determine whether their changes are good.  For text files, CVS provides
  937. this functionality via the `cvs diff' command.  For binary files, it
  938. may be possible to extract the two revisions and then compare them with
  939. a tool external to CVS (for example, word processing software often has
  940. such a feature).  If there is no such tool, one must track changes via
  941. other mechanisms, such as urging people to write good log messages, and
  942. hoping that the changes they actually made were the changes that they
  943. intended to make.
  944.  
  945.    Another ability of a version control system is the ability to merge
  946. two revisions.  For CVS this happens in two contexts.  The first is
  947. when users make changes in separate working directories (*note Multiple
  948. developers::.).  The second is when one merges explicitly with the
  949. `update -j' command (*note Branching and merging::.).
  950.  
  951.    In the case of text files, CVS can merge changes made independently,
  952. and signal a conflict if the changes conflict.  With binary files, the
  953. best that CVS can do is present the two different copies of the file,
  954. and leave it to the user to resolve the conflict.  The user may choose
  955. one copy or the other, or may run an external merge tool which knows
  956. about that particular file format, if one exists.  Note that having the
  957. user merge relies primarily on the user to not accidentally omit some
  958. changes, and thus is potentially error prone.
  959.  
  960.    If this process is thought to be undesirable, the best choice may be
  961. to avoid merging.  To avoid the merges that result from separate
  962. working directories, see the discussion of reserved checkouts (file
  963. locking) in *Note Multiple developers::.  To avoid the merges resulting
  964. from branches, restrict use of branches.
  965.  
  966. 
  967. File: cvs.info,  Node: Binary howto,  Prev: Binary why,  Up: Binary files
  968.  
  969. How to store binary files
  970. =========================
  971.  
  972.    There are two issues with using CVS to store binary files.  The
  973. first is that CVS by default converts line endings between the
  974. canonical form in which they are stored in the repository (linefeed
  975. only), and the form appropriate to the operating system in use on the
  976. client (for example, carriage return followed by line feed for Windows
  977. NT).
  978.  
  979.    The second is that a binary file might happen to contain data which
  980. looks like a keyword (*note Keyword substitution::.), so keyword
  981. expansion must be turned off.
  982.  
  983.    The `-kb' option available with some CVS commands insures that
  984. neither line ending conversion nor keyword expansion will be done.
  985.  
  986.    Here is an example of how you can create a new file using the `-kb'
  987. flag:
  988.  
  989.      $ echo '$Id$' > kotest
  990.      $ cvs add -kb -m"A test file" kotest
  991.      $ cvs ci -m"First checkin; contains a keyword" kotest
  992.  
  993.    If a file accidentally gets added without `-kb', one can use the
  994. `cvs admin' command to recover.  For example:
  995.  
  996.      $ echo '$Id$' > kotest
  997.      $ cvs add -m"A test file" kotest
  998.      $ cvs ci -m"First checkin; contains a keyword" kotest
  999.      $ cvs admin -kb kotest
  1000.      $ cvs update -A kotest
  1001.      # For non-unix systems:
  1002.      # Copy in a good copy of the file from outside CVS
  1003.      $ cvs commit -m "make it binary" kotest
  1004.  
  1005.    When you check in the file `kotest' the file is not preserved as a
  1006. binary file, because you did not check it in as a binary file.  The `cvs
  1007. admin -kb' command sets the default keyword substitution method for
  1008. this file, but it does not alter the working copy of the file that you
  1009. have.  If you need to cope with line endings (that is, you are using
  1010. CVS on a non-unix system), then you need to check in a new copy of the
  1011. file, as shown by the `cvs commit' command above.  On unix, the `cvs
  1012. update -A' command suffices.
  1013.  
  1014.    However, in using `cvs admin -k' to change the keyword expansion, be
  1015. aware that the keyword expansion mode is not version controlled.  This
  1016. means that, for example, that if you have a text file in old releases,
  1017. and a binary file with the same name in new releases, CVS provides no
  1018. way to check out the file in text or binary mode depending on what
  1019. version you are checking out.  There is no good workaround for this
  1020. problem.
  1021.  
  1022.    You can also set a default for whether `cvs add' and `cvs import'
  1023. treat a file as binary based on its name; for example you could say
  1024. that files who names end in `.exe' are binary.  *Note Wrappers::.
  1025. There is currently no way to have CVS detect whether a file is binary
  1026. based on its contents.  The main difficulty with designing such a
  1027. feature is that it is not clear how to distinguish between binary and
  1028. non-binary files, and the rules to apply would vary considerably with
  1029. the operating system.
  1030.  
  1031. 
  1032. File: cvs.info,  Node: Multiple developers,  Next: Revision management,  Prev: Binary files,  Up: Top
  1033.  
  1034. Multiple developers
  1035. *******************
  1036.  
  1037.    When more than one person works on a software project things often
  1038. get complicated.  Often, two people try to edit the same file
  1039. simultaneously.  One solution, known as "file locking" or "reserved
  1040. checkouts", is to allow only one person to edit each file at a time.
  1041. This is the only solution with some version control systems, including
  1042. RCS and SCCS.  Currently the usual way to get reserved checkouts with
  1043. CVS is the `cvs admin -l' command (*note admin options::.).  This is
  1044. not as nicely integrated into CVS as the watch features, described
  1045. below, but it seems that most people with a need for reserved checkouts
  1046. find it adequate.  It also may be possible to use the watches features
  1047. described below, together with suitable procedures (not enforced by
  1048. software), to avoid having two people edit at the same time.
  1049.  
  1050.    The default model with CVS is known as "unreserved checkouts".  In
  1051. this model, developers can edit their own "working copy" of a file
  1052. simultaneously.  The first person that commits his changes has no
  1053. automatic way of knowing that another has started to edit it.  Others
  1054. will get an error message when they try to commit the file.  They must
  1055. then use CVS commands to bring their working copy up to date with the
  1056. repository revision.  This process is almost automatic.
  1057.  
  1058.    CVS also supports mechanisms which facilitate various kinds of
  1059. communcation, without actually enforcing rules like reserved checkouts
  1060. do.
  1061.  
  1062.    The rest of this chapter describes how these various models work,
  1063. and some of the issues involved in choosing between them.
  1064.  
  1065. * Menu:
  1066.  
  1067. * File status::                 A file can be in several states
  1068. * Updating a file::             Bringing a file up-to-date
  1069. * Conflicts example::           An informative example
  1070. * Informing others::            To cooperate you must inform
  1071. * Concurrency::                 Simultaneous repository access
  1072. * Watches::                     Mechanisms to track who is editing files
  1073. * Choosing a model::            Reserved or unreserved checkouts?
  1074.  
  1075. 
  1076. File: cvs.info,  Node: File status,  Next: Updating a file,  Up: Multiple developers
  1077.  
  1078. File status
  1079. ===========
  1080.  
  1081.    Based on what operations you have performed on a checked out file,
  1082. and what operations others have performed to that file in the
  1083. repository, one can classify a file in a number of states.  The states,
  1084. as reported by the `status' command, are:
  1085.  
  1086. Up-to-date
  1087.      The file is identical with the latest revision in the repository
  1088.      for the branch in use.
  1089.  
  1090. Locally Modified
  1091.      You have edited the file, and not yet committed your changes.
  1092.  
  1093. Locally Added
  1094.      You have added the file with `add', and not yet committed your
  1095.      changes.
  1096.  
  1097. Locally Removed
  1098.      You have removed the file with `remove', and not yet committed
  1099.      your changes.
  1100.  
  1101. Needs Checkout
  1102.      Someone else has committed a newer revision to the repository.
  1103.      The name is slightly misleading; you will ordinarily use `update'
  1104.      rather than `checkout' to get that newer revision.
  1105.  
  1106. Needs Patch
  1107.      Like Needs Checkout, but the CVS server will send a patch rather
  1108.      than the entire file.  Sending a patch or sending an entire file
  1109.      accomplishes the same thing.
  1110.  
  1111. Needs Merge
  1112.      Someone else has committed a newer revision to the repository, and
  1113.      you have also made modifications to the file.
  1114.  
  1115. File had conflicts on merge
  1116.      This is like Locally Modified, except that a previous `update'
  1117.      command gave a conflict.  If you have not already done so, you
  1118.      need to resolve the conflict as described in *Note Conflicts
  1119.      example::.
  1120.  
  1121. Unknown
  1122.      CVS doesn't know anything about this file.  For example, you have
  1123.      created a new file and have not run `add'.
  1124.  
  1125.    To help clarify the file status, `status' also reports the `Working
  1126. revision' which is the revision that the file in the working directory
  1127. derives from, and the `Repository revision' which is the latest
  1128. revision in the repository for the branch in use.
  1129.  
  1130.    The options to `status' are listed in *Note Invoking CVS::.  For
  1131. information on its `Sticky tag' and `Sticky date' output, see *Note
  1132. Sticky tags::.  For information on its `Sticky options' output, see the
  1133. `-k' option in *Note update options::.
  1134.  
  1135.    You can think of the `status' and `update' commands as somewhat
  1136. complementary.  You use `update' to bring your files up to date, and you
  1137. can use `status' to give you some idea of what an `update' would do (of
  1138. course, the state of the repository might change before you actually run
  1139. `update').  In fact, if you want a command to display file status in a
  1140. more brief format than is displayed by the `status' command, you can
  1141. invoke
  1142.  
  1143.      $ cvs -n -q update
  1144.  
  1145.    The `-n' option means to not actually do the update, but merely to
  1146. display statuses; the `-q' option avoids printing the name of each
  1147. directory.  For more information on the `update' command, and these
  1148. options, see *Note Invoking CVS::.
  1149.  
  1150. 
  1151. File: cvs.info,  Node: Updating a file,  Next: Conflicts example,  Prev: File status,  Up: Multiple developers
  1152.  
  1153. Bringing a file up to date
  1154. ==========================
  1155.  
  1156.    When you want to update or merge a file, use the `update' command.
  1157. For files that are not up to date this is roughly equivalent to a
  1158. `checkout' command: the newest revision of the file is extracted from
  1159. the repository and put in your working copy of the module.
  1160.  
  1161.    Your modifications to a file are never lost when you use `update'.
  1162. If no newer revision exists, running `update' has no effect.  If you
  1163. have edited the file, and a newer revision is available, CVS will merge
  1164. all changes into your working copy.
  1165.  
  1166.    For instance, imagine that you checked out revision 1.4 and started
  1167. editing it.  In the meantime someone else committed revision 1.5, and
  1168. shortly after that revision 1.6.  If you run `update' on the file now,
  1169. CVS will incorporate all changes between revision 1.4 and 1.6 into your
  1170. file.
  1171.  
  1172.    If any of the changes between 1.4 and 1.6 were made too close to any
  1173. of the changes you have made, an "overlap" occurs.  In such cases a
  1174. warning is printed, and the resulting file includes both versions of
  1175. the lines that overlap, delimited by special markers.  *Note update::,
  1176. for a complete description of the `update' command.
  1177.  
  1178. 
  1179. File: cvs.info,  Node: Conflicts example,  Next: Informing others,  Prev: Updating a file,  Up: Multiple developers
  1180.  
  1181. Conflicts example
  1182. =================
  1183.  
  1184.    Suppose revision 1.4 of `driver.c' contains this:
  1185.  
  1186.      #include <stdio.h>
  1187.      
  1188.      void main()
  1189.      {
  1190.          parse();
  1191.          if (nerr == 0)
  1192.              gencode();
  1193.          else
  1194.              fprintf(stderr, "No code generated.\n");
  1195.          exit(nerr == 0 ? 0 : 1);
  1196.      }
  1197.  
  1198. Revision 1.6 of `driver.c' contains this:
  1199.  
  1200.      #include <stdio.h>
  1201.      
  1202.      int main(int argc,
  1203.               char **argv)
  1204.      {
  1205.          parse();
  1206.          if (argc != 1)
  1207.          {
  1208.              fprintf(stderr, "tc: No args expected.\n");
  1209.              exit(1);
  1210.          }
  1211.          if (nerr == 0)
  1212.              gencode();
  1213.          else
  1214.              fprintf(stderr, "No code generated.\n");
  1215.          exit(!!nerr);
  1216.      }
  1217.  
  1218. Your working copy of `driver.c', based on revision 1.4, contains this
  1219. before you run `cvs update':
  1220.  
  1221.      #include <stdlib.h>
  1222.      #include <stdio.h>
  1223.      
  1224.      void main()
  1225.      {
  1226.          init_scanner();
  1227.          parse();
  1228.          if (nerr == 0)
  1229.              gencode();
  1230.          else
  1231.              fprintf(stderr, "No code generated.\n");
  1232.          exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
  1233.      }
  1234.  
  1235. You run `cvs update':
  1236.  
  1237.      $ cvs update driver.c
  1238.      RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
  1239.      retrieving revision 1.4
  1240.      retrieving revision 1.6
  1241.      Merging differences between 1.4 and 1.6 into driver.c
  1242.      rcsmerge warning: overlaps during merge
  1243.      cvs update: conflicts found in driver.c
  1244.      C driver.c
  1245.  
  1246. CVS tells you that there were some conflicts.  Your original working
  1247. file is saved unmodified in `.#driver.c.1.4'.  The new version of
  1248. `driver.c' contains this:
  1249.  
  1250.      #include <stdlib.h>
  1251.      #include <stdio.h>
  1252.      
  1253.      int main(int argc,
  1254.               char **argv)
  1255.      {
  1256.          init_scanner();
  1257.          parse();
  1258.          if (argc != 1)
  1259.          {
  1260.              fprintf(stderr, "tc: No args expected.\n");
  1261.              exit(1);
  1262.          }
  1263.          if (nerr == 0)
  1264.              gencode();
  1265.          else
  1266.              fprintf(stderr, "No code generated.\n");
  1267.      <<<<<<< driver.c
  1268.          exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
  1269.      =======
  1270.          exit(!!nerr);
  1271.      >>>>>>> 1.6
  1272.      }
  1273.  
  1274. Note how all non-overlapping modifications are incorporated in your
  1275. working copy, and that the overlapping section is clearly marked with
  1276. `<<<<<<<', `=======' and `>>>>>>>'.
  1277.  
  1278.    You resolve the conflict by editing the file, removing the markers
  1279. and the erroneous line.  Suppose you end up with this file:
  1280.      #include <stdlib.h>
  1281.      #include <stdio.h>
  1282.      
  1283.      int main(int argc,
  1284.               char **argv)
  1285.      {
  1286.          init_scanner();
  1287.          parse();
  1288.          if (argc != 1)
  1289.          {
  1290.              fprintf(stderr, "tc: No args expected.\n");
  1291.              exit(1);
  1292.          }
  1293.          if (nerr == 0)
  1294.              gencode();
  1295.          else
  1296.              fprintf(stderr, "No code generated.\n");
  1297.          exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
  1298.      }
  1299.  
  1300. You can now go ahead and commit this as revision 1.7.
  1301.  
  1302.      $ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
  1303.      Checking in driver.c;
  1304.      /usr/local/cvsroot/yoyodyne/tc/driver.c,v  <--  driver.c
  1305.      new revision: 1.7; previous revision: 1.6
  1306.      done
  1307.  
  1308.    For your protection, CVS will refuse to check in a file if a
  1309. conflict occurred and you have not resolved the conflict.  Currently to
  1310. resolve a conflict, you must change the timestamp on the file.  In
  1311. previous versions of CVS, you also needed to insure that the file
  1312. contains no conflict markers.  Because your file may legitimately
  1313. contain conflict markers (that is, occurrences of `>>>>>>> ' at the
  1314. start of a line that don't mark a conflict), the current version of CVS
  1315. will print a warning and proceed to check in the file.
  1316.  
  1317.    If you use release 1.04 or later of pcl-cvs (a GNU Emacs front-end
  1318. for CVS) you can use an Emacs package called emerge to help you resolve
  1319. conflicts.  See the documentation for pcl-cvs.
  1320.  
  1321.